A distributed control system (DCS) is a control system consisting of multiple control devices which are distributed throughout an industrial plant, where the industrial plant may belong to different industry sectors, such as the process industry like pharmaceutical and chemical industry, or the discrete manufacturing industry, or the mineral and oil and gas industry, or the power generation industry.
The DCS comprises at least two industrial control devices, each of them being arranged to control operation of a respective actuating part of the industrial plant during a production process of the industrial plant, where the actuating parts may be, for example, single actuators such as a motor, a pump, a valve or a switch, groups of actuators, or a whole operational section of the industrial plant. In order to be able to control the corresponding at least one actuator, each control device is arranged to receive or determine state information about a current operational state of the respective actuating part of the industrial plant, where the state information is generated directly from measurements taken by at least one sensor, or indirectly, by estimating the state information from available further state information. The DCS further comprises at least one data communication means arranged to connect each of the at least two industrial control devices with at least the respective actuating part of the industrial plant. The data communication means are preferably wire-bound or wireless field busses, applying protocols such as Foundation Fieldbus, Profibus and Profinet or IEC61850.
Before the parts of a new or amended DCS are delivered to and/or installed in the actual industrial plant, their operation needs to be tested during a so called Factory Acceptance Testing (FAT). This is commonly performed in a dedicated test environment which contains certain samples of the hardware to be expected in the industrial plant. However, it is never possible to provide more than a sub-system of the industrial plant and the corresponding—already tested—parts of the DCS for testing a particular control device. In particular, peripheral components of the DCS, such as field bus components, are usually sent directly to the site due to reasons of easier logistics and economy of time. However, in order to ensure that the whole DCS works correctly and fulfills all specifications, it is desirable to test as many parts of the DCS in a concurrent test procedure as possible, notwithstanding the above described hardware limitations in the test environment.
In an article by M. Hoernicke et al: “Effizientes Testen heterogener Leitsystemkonfigurationen,” it is described that the hardware limitations during FAT are overcome by using simulation in order to reproduce the dynamic behavior of the production processes performed in the industrial plant, and by using emulation for those parts of the DCS which are not available in hardware. The simulation is commonly based on a computer-implemented model of the dynamic system behavior of the operational elements of the industrial plant, thereby modeling the production processes performed in the plant. In the simulation model, the output signals, i.e. the actuating signals, of the control devices are used as input variables, and at least some of the operational states of the industrial plant represent the output variables.
The emulation of the elements of the DCS is performed by executing the original computer programs written for the control devices and the data communication means of the DCS on alternative hardware devices than the original hardware devices used in the industrial plant, where the alternative hardware devices mimic the computational and processing related behavior of the original hardware. The alternative hardware devices may for example be a so called emulating computer device having a higher processing power than a typical control device of the DCS, such as a PC versus a microcontroller. On this emulating computer device, several emulated control devices may be running in parallel. Accordingly, the control devices are emulated in software only, meaning that the processing related behavior of the control devices is imitated by appropriate software programs, called soft emulators. The alternative hardware devices may also be dedicated hardware emulators having the same physical input and output signals as the imitated control devices or data communication means of the DCS, i.e. a hardware emulator is a piece of hardware which mimics the behavior of the original piece of hardware. Such hardware emulators may be used in particular for emulating the data communication means of the DCS, such as field bus systems and I/O devices.
As a result, the above named article presents a combination of simulation and emulation which results in a so called digital factory that can be used for virtual commissioning and therefore as a test environment for FAT.
In DE 10 2010 025 954 A1, another approach for realizing a test environment for FAT of a DCS is presented, as is shown in appended FIG. 1. It is suggested to virtualize each of the DCS elements on a host computer system, in order to be able to simulate the DCS together with a simulation of the production process of the industrial plant on the host computer system. Accordingly, each control device is virtualized by providing a corresponding virtual processor and virtual interfaces on the host computer system, and the data communication means are virtualized via virtual field busses and virtual field bus interfaces implemented on the host computer system. The emulation described in the article by M. Hoernicke et. Al. and the virtualization used in DE 10 2010 025 954 A1 are different techniques for simulating hardware. Emulated hardware is imitated in all details of its behavior by providing for example the complete instruction set of an emulated processor. Virtualized hardware, on the other hand, uses the instruction set of the host computer as far as possible, and only imitates particular instructions which require specific processing activities usually not available on the host computer.
As is further described in DE 10 2010 025 954 A1, the original program of a control device may on one hand be executed directly on its corresponding virtual processor, if the virtual processor and the host computer are alike. In an alternative solution, the virtual processor of a control device may be provided in the form of a hardware emulator, running inside the virtualization environment of the host computer system. Apart from that there may be particular cases where the hardware of the DCS control device differs considerably from the hardware of the host computer system, such as for microcontrollers, so that the hardware emulator of the processor cannot be virtualized without greater effort. In these cases, it is arranged for the hardware emulator to run in parallel with and on the same level as the virtualization layer of the host computer system. In the resulting simulation environment for the DCS, the original software programs may then be executed on their respective purely virtualized, purely emulated or mixed virtualized-emulated processors.
Commonly, the configuration of the above described versions of a digital factory is a highly manual process, as each virtual device and/or emulator has to be configured separately and individually. In large DCS with several sub-systems and a complex periphery, the virtual devices and/or emulators need to be adapted to one another as precisely as possible. Due to the necessary interconnection of the virtual devices and/or emulators, the resulting digital factory may achieve a complexity of almost the same degree as the real industrial plant.
The configuration is done based on the engineering results of the DCS, i.e. the virtual devices and/or emulators are configured with the engineering data generated during the designing, verification and validation of each individual element of the DCS. The pure emulation as presented in above cited article requires in addition that the emulating computer devices which finally execute the soft emulators are configured in hardware and software, in order to fit the requirements for each emulator instance. Besides that, the IT infrastructure needed to physically connect the hardware emulators and the emulating computer devices has to be maintained throughout the use of the digital factory.
Even further, the simulation model of the production processes is assembled manually. The model is integrated into a process model simulator and the connection between the emulators and the process model simulator is configured based on the engineering results, as well.
The described manual configuration of the digital factory involves a lot of effort, not only for the configuration but also for providing the test environment as such. In particular, since the test environment is hardly scalable, manual hardware adaptations may become necessary in case that during engineering more processing power, memory or external interfaces is required. After the FAT, the emulation and simulation infrastructure—which is fixedly adapted to the one digital factory—has to be deconstructed in order to get a clean environment for the next project. If during subsequent engineering steps, elements of the DCS are changed or added and therefore the engineering data are amended, a considerable amount of manual effort is required to implement such amendments in the digital factory in case that they result in the requirement of new emulators.
In order to overcome these drawbacks, the above cited article suggests integrating the different emulators of the digital factory in a virtual environment, so that the test environment becomes scalable and independent of any emulation hardware.
The concept presented in the article is based on the automatic generation of one or multiple virtual machines (VM), where in each of the virtual machines multiple emulators are instantiated. The virtual machines may then be freely distributed across multiple emulating computer devices in order to be executed, where the distribution is carried out using a particularly developed tool. An example for such a tool is given in EP 2 508 904 A1, named framework application.
The automatic generation of virtual machines is based on one template of a virtual machine which is then duplicated as often as required. In the template, the different types of soft emulators required for the emulation of the control devices and the data communication means of the DCS are installed, as is shown in the example of FIG. 2. The term “Soft PLC” stands for soft emulator for programmable logic controller.
In order to automatically generate the virtual machines and to instantiate the soft emulators, the article by M. Hoernicke et al. suggests exporting the topology of the DCS from the engineering environment of the DCS, identifying from the topology the required emulator types, generating configuration files for those elements of the DCS which are selected by a user to be simulated, determining and generating the required number of virtual machines based on the selected DCS elements under consideration of certain limitations. The limitations include a maximum number of executable instances of one emulator type per virtual machine, a maximum number of available communication interfaces per virtual machine, a maximum number of objects concurrently executed by one emulator, and a maximum available real working memory per emulating computer device. The article by M. Hoernicke et al. additionally suggests configuring the soft emulators in the virtual machines including configuration of their communication interfaces, distributing the virtual machines across the emulating computer devices, starting the virtual machines, and loading the previously generated configuration files of the DCS elements to the respective soft emulators.